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MOBILE APPLICATION SECURITY SYSTEM AND METHOD 
Related Application 

This application is a continuation in part of US Patent Application No. 09/591,034, filed 
June 9, 2000 and entitled "Mobile Application Security System and Method" which is owned by 
the same assignee as the present invention. 

Background of the Invention 

This invention relates generally to a system and method for enhancing the operation and 
security of a software application and in particular to a system and method for improving the 
security of a mobile software application. 

In traditional computing systems, communication between computers is either code (a 
software appHcation) or data ( a file containing information) and there is no notion of a program 
moving between hosts while it is being executed. Thus, with a typical computing system, a 
person may execute a software application (e.g., Microsoft Word) on his own computer and then 
forward the results of the execution of the software application (e.g., a Word document) to 
another user. The other user may then view the Word document by executing his own copy of 
Microsoft Word, A user may also send another user an executable software application file that 
the other user may download and execute on his own computer. However, these traditional 
computing systems do not recognize a single instantiation of a software program that may be 
executed by one or more different computers in order to complete the execution of the software 
appHcation. 
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A mobile application, sometimes also called a mobile app or a mobile agent, is a 
currently executing computer software application/program, or part of a currently executing 
computer program that can physically move from one computer to another (between hosts) while 
it is being executed: A mobile application's software may or may not have been previously 
5 installed on a particular computers prior to the arrival of the mobile apphcation. The mobile 
applications are said to jimip from one computer to another computer and the process of jumping 
from one computer to another computer is also referred to as a jump. 

p The process of initiating a jump between computers is commonly known as a dispatch, 

ffl Typically, each mobile apphcation will carry with it an ordered list or tree of hosts which the 

So mobile application must visit during its execution, and such a Hst or tree is called the mobile 

m application's itinerary. An example of a mobile application and it itinerary is described below 

a with reference to Figure 2. The computers that can receive and dispatch mobile applications are 

called hosts. The collection of hosts, computer networks, and software which executes and 

5; supports the mobile appUcations, and the mobile applications themselves, is called the mobile 

1 5 apphcation system. 

A mobile application typically has at least two parts: the state and the code. The state of 
the mobile apphcation contains all of the data stored, carried, and/or computed by the particular 
mobile application. The code of the mobile application is the set of computer instructions which 
the host computer is intended to carry out on behalf of the mobile application during the 
20 execution of the mobile application by the particular host computer. In addition, a mobile 

GrayCary\HV\7059779.1 
1010722-990000 



Attorney Docket No. AdAst-l 101 -3- 

application may have other parts, including an Access Control List (ACL), an itinerary, a 
datastore, an audit log, etc. 

The problem faced by software products that support mobile applications are 
insurmountable security problems. In particular, there are three problems that are most often 
5 cited: 

1) An hostile host can send code with undesirable behavior to another host. Currently, 
there is no way to ensure that an hostile host cannot inject unsafe code into the mobile 
^ application system. 

Ul 2) A mobile apphcation cannot be protected from a hostile host. In particular, when a 

[Mo mobile apphcation arrives at a host and begins execution, that mobile apphcation is at the mercy 

of the host. In other words, there is no guarantee that the host will execute the computer 
m instructions properly. There is not even any guarantee that the host will run any particular 
O software at all; and 

3) A mobile apphcation cannot be securely sent to or received from a host outside of a 
15 group of trusted computers, known as the Trusted Computing Base (TCB). 

A Trusted Computing Base (TCB) is the collection of computers, computer peripherals, 
and commimication networks which must perform all requested operations properly, and must 
not perform extraneous operations, and are trusted to do so, m order to properly complete 
whatever computations are required.. A host outside of the TCB can perform nefarious tasks on 
20 the mobile apphcation. This nefarious behavior cannot be controlled, and it cannot be detected. 
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Therefore, once a mobile application has visited an untrasted host, it could be altered in an 
undesirable way, and therefore is a security hazard. In addition, the mobile apphcation that 
visited the untrusted host can no longer be trusted to execute within the TCB. All of these 
security problems with mobile application need to be overcome before mobile applications 
5 become more accepted as a altemative to traditional computing systems. Thus, it is desirable to 
provide a mobile application security system and method that overcomes the above problems and 
limitations with conventional mobile apphcation systems and it is to this end that the present 
invention is directed so that mobile applications may be used ui most financial, commercial, and 
^ military computer systems. 

OO Summary of the Invention 

The mobile application security system and method increases the overall level of security 
S in using a mobile application. In a preferred embodiment, the system may use a client/server 
Q architecture wherein each host of a mobile application is treated as a chent and a central 

computer is treated as the server. In operation, any time that a mobile apphcation is going to 
1 5 jump between hosts, it must first pass through the central computer so that the central computer 
may perform various security checks. The security checks ensure that the security of the mobile 
application is not compromised and overcomes the above problems with typical mobile 
apphcation systems. In accordance with the preferred embodiment of the invention, the security 
system in accordance with the invention may detect unwanted changes in the code of the mobile 
20 apphcation by comparing the mobile application received firom the sending host with a copy of 
the mobile apphcation in the central computer. This ensures that a host cannot accidentally or 
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purposely inject some unwanted code, such as a viras, into the mobile application. In accordance 
with another embodiment of the invention, the security system may prevent hostile or untrusted 
hosts from transmitting code to the other hosts in the mobile appUcation system. In accordance 
with yet another embodiment of the invention, the security system may prevent unwanted 
5 changes to the code of the mobile appUcation. In yet another embodiment, the system may 

prevent unwanted changes in the itinerary of the mobile application. In yet another embodiment, 
the system may prevent untrusted hosts from initially launching mobile applications. 

Thus, in accordance with the invention, a mobile application security system and method 
fl are provided wherein the system comprises a central computer for controlling the security of a 
:f 0 mobile application system; one or more host computers connected to the server computer 
k1 wherein each host computer executes the mobile appUcation that jumps between the hosts during 
r execution. The central computer fiirther comprises means for monitoring the security of the 
S mobile appUcation as it jumps between the host computers wherein when the mobile appUcation 

; S ii 

S is communicated from a first host to a second host, it passes through the central computer. In 
15 accordance with one embodiment of the invention, the security monitoring further comprises 

means for detecting xmwanted changes in the code associated with the mobile application when 

the mobile application is jumping between hosts. 

In accordance with another embodiment of the invention, the security monitoring ftirther 

comprises means for preventing a host from transmitting hostile code in a mobile appUcation to 
20 another host. In accordance with yet another embodiment of the invention, the security 

monitoring fiirther comprises means for detecting unwanted changes in the state of the mobile 

application. In accordance with yet another embodiment of the invention, the security 
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monitoring further comprises means for detecting unwanted changes in the itinerary of the 
mobile appUcation. In accordance with yet another embodiment of the invention, the security 
monitoring comprises means for preventing untrusted hosts from initially launching mobile 
applications. 

Brief Description of the Drawings 

Figure 1 is a diagram illustrating a typical mobile application and its operation; 

Figure 2 is a diagram illustrating an example of a typical mobile application; 

Figure 3 is a diagram illustrating the movement of a mobile application in a conventional 
peer-to-peer mobile application system; 

Figure 4 is a diagram illustrating a client/server mobile application security system in 
accordance with the invention; 

Figure 5 is a diagram illustrating the operation of the mobile appUcation security system 
of Figure 4; 

Figure 6 is a diagram illustrating more details of the mobile appUcation security system 
shown in Figure 5; 

Figure 7 is a diagram illustrating an example of the process for never retrieving code 
from an untrusted host; 
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Figure 7a is a diagram illustrating a first embodiment of the mobile application security 
system for detecting unwanted changes to the code of a mobile application in accordance with 
the invention; 

Figure 8 is a diagram illustrating a first example of a second embodiment of the mobile 
appUcation security system for preventing hostile hosts fi-om transmitting code to other hosts in 
accordance with the invention; 

Figure 9 is a diagram illustrating a second example of a second embodiment of the 
mobile application security system for preventing hostile hosts firom transmitting code to other 
hosts in accordance with the invention; 

Figure 10 is a diagram illustrating a third example of a second embodiment of the mobile 
appUcation security system for preventing hostile hosts from transmitting code to other hosts in 
accordance with the invention; 

Figure 1 1 is a diagram illustrating a fourth example of a second embodiment of the 
mobile appUcation secxirity system for preventing hostile hosts from transmitting code to other 
hosts in accordance with the invention; 

Figure 12 is a diagram illustrating a third embodiment of the mobile application security 
system for detecting unwanted changes to the state of a mobile application in accordance with 
the invention; 
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Figure 13 is a diagram illustrating a first example of a fourth embodiment of the mobile 
application security system for detecting unwanted changes in the itmerary of the mobile 
application in accordance with the invention; 

Figure 14 is a diagram illustrating a second example of a fourth embodiment of the 
mobile application security system for detecting unwanted changes in the itinerary of the mobile 
apphcation in accordance with the invention; 

Figure 15 is a diagram illustrating a third example of a fourth embodiment of the mobile 
apphcation security system for detecting unwanted changes hi the itmerary of the mobile 
apphcation in accordance with the invention; 

Figure 16 is a diagram illustrating a first example of a fifth embodiment of the mobile 
apphcation security system for preventing untrusted hosts fi:om launching a mobile apphcation in 
accordance with the invention; 

Figure 17 is a diagram illustrating a second example of a fifth embodiment of the mobile 
application security system for preventing untrusted hosts from launching a mobile apphcation in 
accordance with the invention; and 

Figure 18 is a diagram illustrating a third example of a fifth embodiment of the mobile 
apphcation security system for preventing untrusted hosts from launching a mobile application in 
accordance with the invention. 

Detailed Description of a Preferred Embodiment 
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The invention is particularly applicable to a client-server based mobile application 
security system and it is in this context that the invention will be described. It will be 
appreciated, however, that the system and method in accordance with the invention has greater 
utility since it may be used with web-based systems for example. 

5 Figure 1 is a diagram illustrating a typical mobile application 18 and its operation. In 

particular, the mobile appUcation may start its execution on a first computer 20. At some point, 
the mobile application 18 is instructed to move to a second computer 22 and the mobile 

0 application jumps to the second computer. Once at the second computer, the mobile application 

1 resumes its execution on the second computer. At some later time, the mobile application is 

io instructed to move to a third computer 24 and the mobile appUcation jumps to the third computer 

S and resumes its execution on the third computer. In this manner, the mobile application can 

b execute on one or more different computers at different times. To understand the concept of a 

Hi mobile appUcation, an example of a typical mobile appUcation will now be provided. 

S= Figure 2 is a diagram illustrating an example of a typical mobile application and in 

1 5 particular, an intelligent expense report form. In this example, the mobile appUcation faciUtates 
the expense report process by automatically performing some functions. In particular, a 
salesman at a laptop computer 26 may initially fill out an expense report form and click OK 
when the expense report is ready. Automatically, the mobile application then sends itself to a 
manager's computer 28 for approval by the manager. In this example, the manager finds a 
20 problem with the form and returns it to the salesman so that the form automatically sends itself 
back to the salesman for an update. Next, the salesman makes the necessary corrections and 
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clicks OK to send it automatically back to the manager. With the fiirther updates, the manager 
accepts the expense form and clicks "OK". The mobile expense report form then automatically 
sends itself to a computer 30 in the administration department. The mobile expense form then 
executes on the administration computer and updates a database 32 with the new information in 
5 the expense form. Next, the mobile expense report automatically sends itself to a computer 34 of 
the accountant. The mobile expense report then automatically starts to execute on the 
accountant's computer and notifies the accountant that a check is needed so that the accountant 
can cut the check for the salesman. Thus, the mobile application has automated much of the 
3 expense report submission process so that the people involved in the process do not have to 
:f 0 worry about ensuring that the expense report is approved. To better understand the problems 
i associated with the typical mobile application, an example of the movement of the typical mobile 
= appUcation will be described in more detail. 

lU Figure 3 is a diagram illustrating the movement of a mobile application 40 in a 

5 conventional peer-to-peer mobile application system 42. In this example, the system 42 may 
1 5 include one or more host computers, such as Hostl , Host2, Host3, Host4 and Hosts, that execute 
the mobile application are different times as the mobile application jumps between the hosts as is 
well known. As shown in Figure 3, the mobile application 40 may jump directly from one host 
to another host such that there is never a central repository for information about the mobile 
application. Thus, a noted problem with the mobile application from Host 1 may never be 
20 known by the other Hosts. In addition, any of the Hosts in the system 42 may sabotage or alter 
the mobile application to perform some nefarious act, such as placing a virus into the mobile 
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application. It is desirable to provide a system wherein the hosts and the mobile application are 
protected from attacks and the invention solves these problems as will now be described. 

Figure 4 is a diagram illustrating a cUent/server mobile application security system 50 in 
accordance with the invention. In particular, the system may include a server computer 52 and 
one or more host computers 54, such as Host 1, Host 2 and Host N, that may be connected to the 
server computer by a computer network 56, such as a wide area network, the Internet, the World 
Wide Web, a telephone line and a modem or the like. The computer network permits the server 
and hosts to communicate data between each other. Each host may be a typical computer system 
that includes a CPU and a memory for executing a software application such as a mobile 
application. 

The server 52 may include a CPU 58 and a memory 60 along with a persistent storage 
device (not shown) for permanently storing one or more software appUcations or modules that 
may be executed by the CPU by loading the software apphcations or modules into the memory. 
The server may also include a database 62 that stores one or more mobile applications along with 
information about the mobile appUcations as described below. As shown, the memory of the 
server has a mobile apphcation controller module 64 stored in it that, when executed by the CPU, 
control the security of the mobile applications and hosts as described below. In a preferred 
embodiment, the mobile apphcation controller 64 may be one or more software application or 
modules, but the controller may also be implemented using hardware. 

In a preferred embodiment, the mobile apphcation controller 64 may include security 
software 66 and a communications software 68. The combination of the software may solve the 

Gray CaTy\HV\7059779.1 
1010722-990000 



Attorney Docket No. AdAst-1 101 -12- 

problems with typical mobile application systems so that: 1) An hostile host cannot send code 
with undesirable behavior to another host; 2) A mobile apphcation cant be protected from a 
hostile host; and 3) A mobile apphcation can be securely sent to or received from a host outside 
of a group of trusted computers, known as the Trusted Computing Base (TCB) without fear of 
5 hostile activity. The way in which the security system in accordance with the invention 
overcomes these problems will now be described. 

Figure 5 is a diagram illustrating the operation of the mobile application security system 

O 50 of Figure 4. In particular^ the security system 50 in accordance with the invention uses a 

^ client/server based security model as opposed to the typical peer-to-peer arrangement as shown 

3^0 in Figure 3. Thus, using the security system 50 in accordance with the invention, there is 

f2 centralized server 52 which is not a host for the mobile applications, but acts as a server for the 

O participating hosts (Hostl, Host2, Host3, Host4 md Host 5 in this example) that are the clients. 

J Thus, in accordance with the invention, each of these clients (Hosts) communicates with only the 

S server and never directly with each other. Thus, as shown in Figure 5, the mobile application 40 

1 5 must pass through the server on each jump between the hosts. 

Figure 6 is a diagram illustrating more details of the mobile application security system 
50 shown in Figure 5. In particular, the chent/server architecture of the security system in 
accordance with the invention ensures that the server tracks all of the mobile applications in the 
system and all of the jumps of all of the mobile applications. The server 52 may also perform 
20 security procedures on the mobile apphcations while they are in transit. Thus, for example, a 
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security check 70 may be performed by the security module of the server each time a mobile 
appHcation jumps from one host to another host as shown in Figure 6. 

The security system 50 in accordance with the invention provides many advantages over 
the typical mobile application systems. For example, the necessary and feasible security 
5 procedures which the server can perform to ensure the security of the mobile application system 
are provided that raise the level of security of the mobile application system sufficiently to allow 
deployment in most computer systems. The system may also perform and generate certain 
r2 responses to a failure of security checks as described below. 

£ In accordance with the invention, since any mobile application must jump to the server 

jj^O between each host, the server may capture and record the entire mobile application during each 
J" jump. Then, on subsequent jumps, the server can compare the previously saved mobile 
to application with the new (and potentially changed) mobile application to detect unwanted 
y tampering by each host. The above is just one example of the security checks that can be 

performed by the server and the server may also perform other security checks as described 
15 below. In particular, five different embodiments will be described. Now, a first embodiment of 

the security system (referred to as "Jumping Beans") will be described that prevents/detects 

unwanted changes in the mobile application code. 

In accordance with the invention, the system may detect unwanted changes in the code of 
a mobile appUcation and strip unsafe code from mobile appUcations by a combination of three 
20 different processes: 1) never retrieving code from untrusted hosts, (2) preventing untrusted hosts 
from forwarding code, and (3) marking mobile appUcations as having immutable code. With 
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Jumping Beans, each participating host can be marked to operate in one of two ways: 1) The host 
cannot inject any code into the mobile application system, except for code which the host 
provides for execution on itself, or 2) All code supplied by the host can be propagated to other 
hosts in the mobile appHcation system. The hosts are marked this way from the server, so the 
server is aware of how each host is marked. An example of the implementation of the invention 
will now be described. 

Never retrieve code from untrusted hosts 

Jumping Beans mobile apphcations do not necessarily carry with them all of the code 
needed for execution. Jumping Beans implements a protocol for retrieving any code which the 
mobile application might require, and this protocol is part of the implementation: 

a. The mobile application inspects its own internal datastore 47 to see if the required code 
is available there. If it is, the mobile application uses it and searches no ftirther. 

b. If the mobile application cannot find the requested code in its own datastore, the 
mobile application queries the local host for the code. The local host inspects its own pre- 
installed software to determine if the requested code is available there. If it is, the mobile 
appUcation uses it and searches no ftirther. 

c. If the mobile application cannot find the requested code, it forms a request for the 
requested code which is sent to the server. 
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d. The server then checks the host from which the mobile application originated. If this 
host is marked as allowed to inject code into the mobile application system, then the server sends 
a request to the originating host for the requested code. If the requested code is found there, the 
server forwards the code to the mobile application and skips the next step, 

5 e. If the originating host is marked as unable to inject code into the mobile appUcation 

system, or if the originating host does not have the requested code, then the server inspects its 
own previously installed software to see if the requested code is available from the server. If it is 
d available from the server, the requested code is fDrwarded to the mobile appUcation. 

f If the mobile application retrieves the requested code from the server (either from the 
^ originating host or fi-om software pre-installed on the server), then the mobile apphcation stores 
the retrieved code in its own datastore so that it will not need to be retrieved in the future. 

rU g. If the mobile application retrieves the requested code from the server (either from the 

y originating host or from software pre-installed on the server), then the mobile application uses 
that code and searches no fiirther. 

15 h. If the mobile application cannot retrieve the requested code from the server, then an 

exception is raised. Figure 7 illustrates an example of the above process. 

Figure 7a is a diagram illustrating a first embodiment of the mobile appUcation security 
system 50 for detecting unwanted changes to the code of a mobile application in accordance with 
the invention. In particular, the mobile application 40 is created at and resides initially on Hostl . 
20 In this exmaple, the mobile appUcation 40 is assumed to be marked as having immutable code. 
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Hostl then dispatches the mobile application to Host2. In order to do that, the mobile 
application is directed to the server 52 that saves data that may be used to determine if the mobile 
application code has changed at any time. For example, a copy of the mobile application's code 
may be saved in a database, a checksum calculated based on the mobile application code may be 
saved in a database or any other technique may be used where the data may be used to compare 
two different instances of a software application or to compare the same software appUcation at 
different times. 

Next, the server forwards the mobile application to the next host (Host2 in this example). 
At Host2, the mobile appUcation is received, executed and later dispatched to the next host 
(Hosts in this example). To transfer the mobile application to HostS, the server receives the 
mobile application again, stores data representing the mobile application at the current time and 
compares the data of the newly received mobile appUcation with the original data it saved 
initially to check for various security problems and then, provided that the code has not changed, 
forwards the mobile application to Host3. The mobile appUcation then arrives at HostS which 
executes the mobile appUcation. In summary, on each jump, the server can save data about the 
mobile appUcation's code and, on subsequent jumps, the server can compare the previously 
saved data to the current data of the mobile appUcation in order to ensure that nothing was added 
to or removed fi^om the code of the mobile appUcation. Now, a second embodiment of the 
security system in accordance with the invention will be described. 

Prevent untrusted hosts from forwarding code . 
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When a mobile application is dispatched to the server, one of three possible actions is 

taken: 

a. If the host is not allowed to inject code into the system, and the mobile application has 
never been previously dispatched, then the server simply empties all of the mobile application's 

5 code from the mobile apphcation's datastore and saves a copy of the mobile application's empty 
datastore for future use, and then forwards the mobile apphcation to the next host. 

b. If the host is not allowed to inject code into the system, and the mobile application has 
j3 been dispatched in the past, then the server simply restores the mobile application's datastore to 
rf what was saved on the previous jump. 

^ c. If the host is allowed to inject code into the system, then the server inspects the mobile 

application's ACL, as described next. Figures 8-11 illustrate examples of this process. 

y j Figure 8 is a diagram illustrating a first example of a second embodiment of the mobile 

B apphcation security system 50 for preventing hostile hosts from transmitting code to other hosts 
in accordance with the invention. In particular, the mobile application 40 is created by Hostl and 

15 then later dispatched to another host to continue the execution of the mobile application. In this 
example, Hostl is untrusted in that the server 52 does not know whether or not to trust the host 
when interacting with the mobile apphcation. Therefore, the mobile apphcation dispatched from 
Hostl is sent to the server 52 in accordance with the invention and the server may perform 
several security measures. For example, it may strip any code from the mobile apphcation and 

20 store an (empty) copy of the mobile application code in the database 62. The server may 
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altematively check the code to ensure that it is safe and forward only safe code to the next host. 
The server may then forward the mobile application onto the next host, Host2 in this example. 
The mobile apphcation may then be received by and executed by Host2. When the mobile 
appKcation requires code for execution, the tested version of the code may be suppHed to Host2 
5 by the server 52 thus ensuring that the untrusted host cannot spread a vims, for example, using 
the mobile apphcation. Now, the dispatch of a mobile apphcation from a trusted host to another 
host will be described. 

p Figure 9 is a diagram illustrating a second example of a second embodiment of the 

ffl mobile apphcation security system 50 for preventing hostile hosts from transmitting code to 
tfO other hosts in accordance with the invention. Li particular, the mobile application 40 is created 

by Hostl and then later dispatched to another host to contmue the execution of the mobile 
□ application. In this example, Hostl is trusted in that the server 52 knows that the particular host 
nJ is trusted and therefore does not need to strip the code from the mobile application and test it as 
bf described above. Therefore, the mobile apphcation dispatched from Hostl is sent to the server 
15 52 in accordance with the uivention and the server may store a copy of the mobile apphcation 
code in the database 62. The server may then forward the mobile application onto the next host, 
Host2 in this example. The mobile apphcation may then be received by and executed by Host2. 
When the mobile application requires the code for execution, the known safe version of the code 
may be supphed to Host2 by the server 52 or, since the originating host is trusted, the code may 
20 be provided by the originating host. Now, the subsequent dispatch of a mobile application from 
an untrusted host will be described. 
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Figure 10 is a diagram illustrating a third example of a second embodiment of the mobile 
appUcation security system 50 for preventing hostile hosts from transmitting code to other hosts 
in accordance with the invention. In particular, the mobile application 40 is received from 
another host by an untrusted host (Host n) and then later dispatched to another host to continue 
5 the execution of the mobile application. In this example, Host n is untrusted in that the server 52 
does not know whether the particular host may perform nefarious acts on the mobile application 
or using the mobile application. Therefore, the mobile appUcation dispatched from Host n is sent 
to the server 52 in accordance with the invention and the server may perform several security 
C measures. For example, the server may receive the code of the mobile application and compare 
tX) the current code to a previously stored version of the code to ensure that the newly received code 
m is the same as the previous code. The server may then forward the mobile application onto the 
s next host, Host n+1 in this example. The mobile application may then be received by and 
^ executed by Host n+1 . When the mobile appUcation requires code for execution, the known safe 
2 version of the code may be supplied to Host n+1 by the server 52 or, if the originating host is 
15 trusted, the code may be provided by the originating host. Now, the subsequent dispatch of a 
mobile appUcation from a trusted host will be described. 

Figure 1 1 is a diagram illustrating a fourth example of a second embodiment of the 
mobile appUcation security system 50 for preventing hostile hosts from transmitting code to 
other hosts in accordance with the invention. In particular, the mobile application 40 is received 
20 from another host by a trusted host (Host n) and then later dispatched to another host to continue 
the execution of the mobile application. In this example, Host n is trusted in that the server 52 
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knows that the particular host will not perform nefarious acts using the mobile appUcation. 
Therefore, the mobile application dispatched from Host n is sent to the server 52 in accord£mce 
with the invention and the server may perform several security measures. For example, the 
server may receive the code of the mobile apphcation and store a copy of it in the database 62. 
5 No comparison is necessary since the host is trusted. The server may then forward the mobile 
application onto the next host, Host n+1 in this example. The mobile application may then be 
received by and executed by Host n+1. When the mobile application requires the code for 
execution, the known safe version of the code may be suppUed to Host n+1 by the server 52 or, if 
S the originating host is trusted, the code may be provided by the originating host. Now, a third 
JlO embodiment of the mobile apphcation security system will be described. 

a Mark mobile applications as having immutable code . 

ffi The Jumping Beans server may inspects each mobile apphcation' s Access Control List 

^ (ACL) to determine if the code in that mobile application is immutable. One of three possible 
tasks actions is taken: 

15 a. If the mobile application's code cannot be changed, and the mobile appUcation has 

never been dispatched in the past, and the mobile apphcation is being dispatched from a trusted 
host, then the server simply saves the mobile apphcation' s code for later use and the mobile 
application is forwarded to the next host in the itinerary. 

b. If the mobile appHcation's code camot be changed, and the mobile apphcation has 
20 never been dispatched in the past, and the mobile apphcation is being dispatched from an 
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untrusted host, then the server strips the mobile application's code from the mobile application 
and saves the mobile application's (empty) code for later use and the mobile appUcation is 
forwarded to the next host in the itinerary. 

c. If the mobile apphcation's code cannot be changed, and the mobile application has 
been previously dispatched, then the server discards the mobile application's datastore, and 
inserts the datastore saved on the previous jump. 

d. If the mobile apphcation's code can be changed, then the server simply saves the 
mobile application's code and forwards the mobile application to the next host without altering 
its datastore. 

Detect unwanted changes in the mobile apphcation's state 

The Jumping Beans server inspects each mobile apphcation's Access Control List (ACL) 
to determine if the state of that mobile application is immutable. One of three possible actions is 
taken: 

a. If the mobile apphcation's state cannot be changed, and the mobile application has 
never been dispatched in the past, then the server saves the mobile apphcation's state for later use 
and the mobile application is forwarded to the next host in the itinerary; 

b. If the mobile apphcation's code cannot be changed, and the mobile apphcation has 
been previously dispatched, then the server discards the mobile apphcation's state, and inserts 
the state saved on the previous jump. 
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c. If the mobile application's code can be changed, then the server simply saves the 
mobile application's state for later use and the mobile application is forwarded to the next host in 
the itinerary. Figure 12 illustrates an example of the process. 

Figure 12 is a diagram illustrating a third embodiment of the mobile apphcation security 
5 system 50 for detecting unwanted changes to the state of a mobile application in accordance with 
the invention. In general, the server 52 may compare the state of the mobile application on the 
previous jump with the state of the mobile apphcation on the current jump. This allows the 
D server to detect the unwanted changes in the state of the mobile apphcation. In more detail, a 
^1 host, Hostl in this example, may create a mobile apphcation 40 that is then dispatched to other 
3J0 hosts for further execution. When the mobile apphcation 40 is dispatched, it is sent to the server 
m 52 which may save a copy of the mobile application's state. The server may then forward the 
O mobile apphcation to the next host, Host2 in this example. Host2 may receive the mobile 
J ^ application, execute it and then forward it onto the next host. The server may receive the mobile 
S apphcation from the next host and compare the state of the mobile application received from the 
15 next host to the state of the mobile apphcation saved in the database to determine if changes have 
occurred. If the comparison does not detect any unwanted changes with the mobile application, 
the server may forward the mobile apphcation onto the next host. Thus, in this embodiment, a 
host that executes the mobile application is unable to insert changes into the mobile apphcation's 
state since those changes will be identified by the server when the comparison step is executed 
20 by the server. Now, a fourth embodiment of the mobile application security system will be 
described. 
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Enforcing a mobile application's itinerary 

The ACL in a mobile application can indicate whether or not that mobile application's 
itinerary cm be edited. Even if a mobile application's ACL indicates that the mobile 
application's itinerary can be edited, under no circumstances should that portion of an itinerary 
5 which represents the previous history of the mobile application ever be altered, nor should it ever 
be inaccurate. Because each mobile application must pass through the server on each jump, the 
server can accurately track the current and past locations of each mobile appUcation. On a mobile 
n appKcation's first jump, the server simply saves that mobile application's entire itinerary for later 
m use, and then forwards the mobile application to the next host. On subsequent jumps, the server 
yj) inspects the mobile application's ACL, and handles the mobile application's itinerary in one of 
}^ two ways: 

m a. If the mobile application's itinerary can be edited, the server sunply ensures that the 

y past itinerary accurately reflects the mobile application's past visits. If the mobile appUcation's 
past itinerary does not match the server's record, a security exception is thrown. 

15 b. If the mobile application's itinerary can not be edited, the server compares the mobile 

application's entire itinerary to the itinerary saved on the previous jiunp. If there is any 
difference, a security exception is thrown. On every jump, the server saves each mobile 
application's entire itinerary for later use. Figures 13-15 illustrate examples of this process. 

Figure 13 is a diagram illustrating a first example of a fourth embodiment of the mobile 
20 application security system 50 for detecting unwanted changes in the itinerary of the mobile 
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application in accordance with the invention. In general, on each jump of the mobile appUcation, 
the server may determine the host from which the mobile application was dispatched and the 
hosts to which the mobile appUcation is dispatched. In particular, this permits the server 52 to 
enforce the itinerary (e.g., the hosts where the mobile application is going to be executed) of the 
5 mobile application. In more detail, a first host (Host!) may create a mobile apphcation 40 and 
then may dispatch the mobile application to another host through the server 52 in accordance 
with the invention. When the server receives the mobile application 40, the server 52 may store 
a copy of the itinerary of the mobile appUcation in the database 62. The server may then forward 
'■S the mobile apphcation to the next host (Host2) according to the itinerary. Now, another example 
W of the embodiment for detecting changes in the itinerary will be described. 

Figure 14 is a diagram illustrating a second example of a fourth embodiment of the 
O mobile apphcation security system 50 for detecting unwanted changes in the itinerary of the 
fU mobile application in accordance with the invention wherein the itinerary of a mobile appUcation 
^ is already stored in the server. In more detail, a first host (Host n) may dispatch a mobile 
1 5 apphcation 40 to another host through the server 52 in accordance with the invention. When the 
server receives the mobile appUcation 40, the server 52 may compare the current itinerary of the 
mobile appUcation to a stored copy of the itinerary to ensure they match each other. If the 
itineraries match, then the server may forward the mobile appUcation onto the next host (Host 
n+1) that receives the mobile application and executes it. Now, another example of the 
20 embodiment for detectmg changes in the itinerary will be described. 
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Figure 15 is a diagram illustrating a third example of a fourth embodiment of the mobile 
application security system 50 for detecting unwanted changes in the itinerary of the mobile 
application in accordance with the invention wherein the itinerary may be changed. In more 
detail, a first host (Host n) which has received a mobile application 40 from another host may 
5 dispatch the mobile application. The mobile appHcation then passes through the server 52 in 
accordance with the invention. When the server receives the mobile application in accordance 
with the invention, it may ensure that the historical portion of the itinerary is accurate by 
comparing the previously saved itinerary with the new itinerary. If the historical portion of the 

5 itinerary is accurate, the server forwards the mobile appUcation to the next host (Host n+1). 

[ft) Now, a fifth embodiment of the mobile application security system will be described. 

m Figure 16 is a diagram illustrating a first example of a fifth embodiment of the mobile 

0 appHcation security system 50 for preventing untrusted hosts from launching a mobile 

1 ^; application in accordance with the invention. In general, on each jump of the mobile appUcation, 
S the server may determine if the mobile application has previously been in the system. For 

15 example, if the host from which the mobile application is sent is an untrusted host, the server 
may prevent the mobile application from being forwarded to the next host. In more detail, as 
shown in Figure 16, a first host (Hostl) may create a mobile application 40 and then later 
dispatch it to another host. In accordance with the invention, the dispatched mobile application 
first is sent to the server 52. The server 52 may determine that the mobile application is new and 

20 therefore fiuther investigation is necessary. If the server then determines that the particular host 
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is allowed (e.g., is trusted to) to launch mobile applications, the server may forward the mobile 
application to the next host (Host2) so that Host2 receives the mobile appKcation. 

Figure 17 is a diagram illustrating a second example of a fifth embodiment of the mobile 
application security system 50 for preventing untrusted hosts from launching a mobile 
5 appKcation in accordance with the invention. In particular, an untrusted host (Hostl) may create 
a new mobile application that is then later dispatched. The mobile application is then sent 
dispatched to the server 52 first in accordance with the invention. The server 52 determines that 
y the host dispatching the mobile application is untrusted so that the server does not forward the 
5 mobile application to the next host. 

Figure 1 8 is a diagram illustrating a third example of a fifth embodiment of the mobile 
application security system 50 for preventing xmtrusted hosts from launching a mobile 
ffi apphcation in accordance with the invention wherein a subsequent dispatch of the mobile 
U appKcation occurs. In particular, a host (Host n) attempts to dispatch a mobile application to 

another host which must pass through the server 52 in accordance with the invention. When the 
1 5 mobile application is received by the server, the server may determine that the mobile application 
is not new (e.g., the server knows about the mobile application and knows that it is safe) and 
forwards the mobile application to the next host (Host n+1). Now, a summary of how the above 
procedures raise the security level of a mobile application environment will be described. 

The most serious security problem perceived by industry observers is that a mobile 
20 apphcation system allows a hostile host to inject dangerous code into a computing system, and 
there is no way to detect this. By marking a host so that it is not allowed to inject code into the 
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system, the other hosts in the mobile application system do not have to trust any code originating 
from that host. Instead, they only need to trust the server in accordance with the invention. 

Another security problem often cited by industry observers is that an hostile host can 
modify the code of the mobile application to give it undesirable behavior, then forward the 
5 mobile application other hosts in the system. Most (but not all) mobile applications, as deployed 
in real-world systems, will have fixed code, meaning that the code will not change during the 
Ufetime of the mobile application. Virtually all mobile appUcations can be designed so that they 

fj do not require that the code change. On creation, a mobile appUcation's ACL can be set up so 

01 that its code cannot be altered in accordance with the invention. This prevents an hostile host 

from modifying a mobile application's code and forwarding that modified code to other hosts, A 

"tS few (but not many) mobile applications will not need to alter their state during their life-time. 

Q When creating the mobile application, the ACL can be set up so that its state cannot be altered in 
accordance with the invention. 

^ Another security concern often cited by industry observers is that an hostile host can 

1 5 tamper with a mobile appUcation in an unwanted way, and then forward that contaminated 

mobile application to other hosts. This problem is a superset of the problem above. As described 
above, the security technology described in this can protect a mobile application's code. The two 
remaining major pieces of a mobile application are its state and its itinerary. As described 
elsewhere in this document, a mobile application's itinerary can be protected from an hostile 
20 host. The only possible remaining method of attack by a hostile host is to alter the mobile 

application's state. Once a mobile application's code and itinerary are protected, the problem is 
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reduced to the exact same problem faced by distributed computing systems which don't use 
mobility. Systems which don't use mobihty are passing around simple data. As this data is 
passed around, the pre-instalied software on the different computers will respond to, alter, and 
otherwise process this data. The state of a mobile application is just data, exactly the same as the 
data passed around in traditional computing systems. Basically, a mobile application system can 
be seciu*ed by applying the technology described herein. Now, possible responses by the mobile 
application security system to security violations will be described. 

In one embodiment, the server could accept the mobile application from the sending host 
and then destroy the mobile application. In another embodiment, the server could perform the 
security procedures before acknowledging receipt of the mobile application. If the security 
procedures fail, the server could reject the mobile application and leave it on the offending host. 
In yet another embodiment, the server could correct the violation, and then forward the mobile 
application to the next host although this is not possible for all types of security violations. In all 
cases where the security procedures fail, the server should record such events in the audit logs. 

While the foregoing has been with reference to a particular embodiment of the invention, 
it will be appreciated by those skilled in the art that changes ui this embodiment may be made 
without departing from the principles and spirit of the invention, the scope of which is defined by 
the appended claims. 
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Claims : 

1 LA mobile application security system, comprising: 

2 a central computer for controlling the security of a mobile application; 

3 one or more host computers connected to the server computer, each host computer 

4 executing the mobile application that jumps between the hosts during execution; 

5 the central computer further comprising means for monitoring the security of the mobile 

6 application as it jumps between the host computers wherein when the mobile application is 

7 communicated from a first host to a second host, it passes through the central computer; and 
C8 wherein the security monitoring means further comprises means for detecting unwanted 

changes in the code associated with the mobile application when the mobile application is 
^ jumping between hosts. 
1 2. The system of Claim 1, wherein the detecting means further comprises means for 



^^=;2 storing a copy of the mobile application when the mobile application first passes through the 

S3 server, means for receiving the mobile apphcation after it is executed by another host and means 

4 for comparing the code of the mobile application after it is executed by another host to the stored 

5 copy of the mobile apphcation to determine if changes have been made to the code of the mobile 



6 application. 

1 3. The system of Claim 1, wherein the detecting means further comprises means for 

2 computing a checksum of the mobile application when the mobile apphcation first passes 

3 through the server, means for receiving the mobile apphcation after it is executed by another 

4 host, means for computing the checksum of the received mobile apphcation and means for 

5 comparing the checksum of the mobile apphcation after it is executed by another host to the 
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6 stored checksum of the mobile application to determine if changes have been made to the code of 

7 the mobile application, 

1 4. A mobile application security system, comprising: 

2 a central computer for controUuig the security of a mobile application; 

3 one or more host computers connected to the server computer, each host computer 

4 executing the mobile appUcation that jumps between the hosts during execution; 

5 the central computer further comprising means for monitoring the security of the mobile 

6 apphcation as it jumps between the host computers wherein when the mobile application is 
57 communicated from a first host to a second host, it passes through the central computer; and 

wherein the security monitoring means further comprises means for preventing a host 

:^;9 from transmitting hostile code in a mobile application to another host. 
1 5. The system of Claim 4, wherein the preventing mernis further comprises means 



S2 for determining if the host dispatching the mobile application is trusted, means for stripping the 

^ code from an initially received mobile application if the host is not trusted, means for saving the 

o 

^"4 code of the mobile application, and means, when requested by another host, for providing the 



5 code for the mobile application to the requesting host. 

1 6. A mobile application security system, comprising: 

2 a central computer for controlling the security of a mobile application; 

3 one or more host computers connected to the server computer, each host computer 

4 executing the mobile application that jumps between the hosts during execution; 
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5 the central computer further comprising means for monitoring the security of the mobile 

6 application as it jumps between the host computers wherein when the mobile application is 

7 communicated from a first host to a second host, it passes through the central computer; and 

8 wherein security monitoring means further comprises means for detecting unwanted 

9 changes in the state of the mobile application. 

1 7. The system of Claim 6, wherein the detecting means further comprises means for 



2 saving a copy of the state of a received mobile appUcation, means for receiving the same mobile 

3 application after a jump to another host and means for comparing the state of the mobile 
application after the jump to another host with the stored state of the mobile application to ensure 

rt5 that the state of the mobile application has not changed. 



SU 8. A mobile application security system, comprising: 

- 2 a central computer for controlling the security of a mobile application; 

^^'3 one or more host computers connected to the server computer, each host computer 

^4 executing the mobile application that jumps between the hosts during execution; 

5 the central computer further comprising means for monitoring the security of the mobile 

6 apphcation as it jumps between the host computers wherein when the mobile application is 

7 communicated from a first host to a second host, it passes through the central computer; and 

8 wherein the security monitoring means further comprises means for detecting unwanted 

9 changes in the itinerary of the mobile apphcation, 

1 9. The system of Claim 8, wherein the detecting means further comprises means for 

2 saving a copy of the itinerary of a received mobile apphcation, means for receiving the same 

3 mobile application after a jump to another host and means for comparing the itinerary of the 
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4 mobile application after the jump to another host with the stored itinerary of the mobile 

5 application to ensure that the itinerary of the mobile application has not changed. 

1 10. The system of Claim 8, wherein the itinerary comprises past historical itinerary 

2 data. 

1 1 1 . A mobile appKcation security method, comprising: 

2 receiving a mobile appUcation at a central computer each time the mobile application is 

3 jumping between a first host and a second host; and 

4 monitoring the security of the mobile appHcation as it jumps between the host computers, 
IB wherein the security monitoring further comprises detecting unwanted changes in the code 

jfe associated with the mobile application when the mobile appUcation is jumping between hosts. 

12. The method of Claim 1 1, wherein the detecting further comprises storing a copy 

- 2 of the mobile application when the mobile apphcation first passes through the server, receiving 

ffi3 the mobile application after it is executed by another host and comparing the code of the mobile 

.^,4 application after it is executed by another host to the stored copy of the mobile application to 

™5 determine if changes have been made to the code of the mobile application, 

1 13, A mobile application security method, comprising: 

2 receiving a mobile application at a central computer each time the mobile application is 

3 jumping between a first host and a second host; and 

4 monitoring the security of the mobile appUcation as it jumps between the host computers, 

5 wherein the security monitoring further comprises preventing a host from transmitting hostile 

6 code in a mobile appUcation to another host. 
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1 14. The method of Claim 13, wherein the preventing further comprises determining if 

2 the host dispatching the mobile application is trusted, stripping the code from an initially 

3 received mobile application if the host is not trusted, saving the code of the mobile apphcation, 

4 and, v^hen requested by another host, providing the code for the mobile application to the 

5 requesting host. 

1 1 5 . A mobile application security method, comprising: 

2 receiving a mobile application at a central computer each time the mobile application is 

3 jumping between a first host and a second host; and 

&i- monitoring the security of the mobile application as it jumps between the host computers, 

wherein the security monitoring further comprises detecting unwanted changes in the 

5l6 state of the mobile application. 

B 1 16. The method of Claim 1 5, wherein the detecting further comprises saving a copy of 



^2 the state of a received mobile application, receiving the same mobile application after a jump to 
Ji"3 another host and comparing the state of the mobile application after the jump to another host 
"^ 4 with the stored state of the mobile application to ensure that the state of the mobile application 



5 has not changed. 

1 1 7 . A mobile application security method, comprising: 

2 receivuig a mobile application at a central computer each time the mobile application is 

3 jumping between a first host and a second host; and 

4 monitoring the security of the mobile application as it jumps between the host computers, 

5 wherein the security monitoring further comprises detecting imwanted changes in the itinerary of 

6 the mobile apphcation. 
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1 18. The method of Claim 17, wherein the detecting further comprises saving a copy of 

2 the itinerary of a received mobile appUcation, receiving the same mobile application after a jump 

3 to another host and comparing the itinerary of the mobile application after the jump to another 

4 host with the stored itinerary of the mobile application to ensure that the itinera of the mobile 

5 application has not changed. 

1 1 9. The method of Claim 1 7, wherein the itinerary comprises past historical itinerary 

2 data. 

1 20. A mobile apphcation security method, comprising: 

receiving a mobile apphcation at a central computer each time the mobile ^plication is 

^5 jumping between a first host and a second host; and 

"^A monitoring the security of the mobile apphcation as it jumps between the host computers, 

5 wherein the security monitoring fiirther comprises preventing untrusted hosts from initially 

]06 launching mobile applications 
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ABSTRACT OF THE DISCLOS URE 

The mobile application security system and method in accordance with the invention 
increases the overall level of security in using a mobile application. In a preferred embodiment, 
the system may use a cUent/server architecture wherein each host of a mobile application is 
treated as a client and a central computer is treated as the server. In operation, any time that a 
mobile application is going to jump between hosts, it must first pass through the central 
computer so that the central computer may perform various security checks. The security checks 
ensure that the security of the mobile application is not compromised and overcomes the above 
problems with typical mobile application systems. 
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